其中使用了两个参数

--single-transaction   此选项会将隔离级别设置为：REPEATABLE READ。并且随后再执行一条START TRANSACTION语句，让整个数据在dump过程中保证数据的一致性，这个选项对InnoDB的数据表很有用，且不会锁表。但是这个不能保证MyISAM表和MEMORY表的数据一致性。   为了确保使用--single-transaction命令时，保证dump文件的有效性。需没有下列语句ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE，因为一致性读不能隔离上述语句。所以如果在dump过程中，使用上述语句，可能会导致dump出来的文件数据不一致或者不可用。   如何验证上述的过程呢，可以开启general log看看过程是否如上述所说。

--default-character-set=utf8 导出的dump文件字符集为uft8，检验文件字符集的命令可以使用file -i

通用查询日志文件如下:

从上述日志分析: SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ 设置隔离级别为REPEATABLE READ START TRANSACTION 开启了事务   事务的实现是通过InnoDB存储引擎的MVCC机制事项，细节如下:InnoDB是一个多版本控制的存储引擎。它可以对已修改的行保留一个旧版本的数据信息。用于支持事务特性。例如：并发和数据回滚。这个信息保留在数据结构中的表空间中，这个表空间称之为rollback segment回滚段。(在Oracle中也有一种类似的数据结构)。   当事务需要回滚的时候，InnoDB会使用回滚段的信息，用于执行undo操作。对于某一行，InnoDB会用早先版本的信息来保障读一致性(consistent read)。   Undo日志在回滚段(rollback segment)中被分为两部分，一部分叫做插入undo日志(insert undo logs)，另外一部分叫做更新undo日志(update undo logs)。插入undo日志只用于事务回滚，如事务一旦提交，那么日志就可以被丢弃。更新undo日志用在读一致性，InnoDB会指定一个数据快照，这个快照的构建来自于更新undo日志中数据行的早期版本。通过数据行早期版本的快照来保证读一致性，如果不需要这种事务数据保护的时候，这个日志可以被丢弃。

可以看到通过REPEATABLE READ事务，保证数据一致性数据，然后 设置保存点sp，当读取了所有数据的快照，就回退这个保存点sp。可以比喻为游戏中存档之后，然后取档备份成一个游戏外的文件，删除这个档。可以当作这个档在这个游戏内不存在。

就算修改了全局事务级别，Mysqldump导出时也会设定隔离事务级别为：REPEATABLE READ。用于保证数据的读一致性。